IBIS Macromodel Task Group Meeting date: 20 November 2018 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Brad Brim Kumar Keshavan Ken Willis eASIC: David Banas GlobalFoundries: Steve Parker IBM Luis Armenta Trevor Timpane Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao Radek Biernacki Ming Yan * Stephen Slater * Maziar Farahmand Mentor, A Siemens Business: John Angulo * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft: * Walter Katz Mike LaBonte SPISim: Wei-hsing Huang Synopsys: Rita Horner Kevin Li Teraspeed Consulting Group: Scott McMorrow Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that the only ATM meetings we expect to cancel in the upcoming weeks are those on December 25th and January 1st. ------------- Review of ARs: - Randy to investigate if/why/how a clock waveform input might be used. - In progress. Arpad noted that Randy had said he was unable to attend today and next week, but that he expected to have some slides on this topic when he returns. - Michael M. to investigate if/why/how a clock waveform input might be used. - In progress. Michael M. noted that he also expected to have some feedback in a few weeks. - Arpad to send an email to si-list seeking input from redriver vendors on the AMI redriver flow. - Done. No replies received thus far. - Walter to send draft2 of the DC_Offset BIRD to ATM. Mike L. to post it. - Done. Walter sent a draft3 in response to some comments from Mike L. on draft2. Mike L. posted draft3. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the November 13 meeting. Walter moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: DC_Offset BIRD Draft: Walter noted that he had nothing new to share, and that draft3 was published and awaiting comments and corrections. Fangyi noted the previous meeting's discussion about whether this parameter applied to Tx. He said a related question was whether or not the Tx equalization could affect the bias (DC_Offset). He noted that the current standard left open this possibility, though it is not an issue for differential signals. However, for single-ended signals we might want to clarify things. Walter said DC_Offset is currently an In parameter. If someone thinks it's useful to be able to modify it, then we could make it InOut or Out. Walter said he wasn't sure what it means for the Tx to change the DC_Offset or what the EDA tool would do with the value. Fangyi noted that he was not requesting that it be an Out. He was simply asking what we would do about a situation in which the Tx equalization were allowed to change the DC_Offset. Fangyi noted an arbitrary amplifier in the Tx could affect the Tx swing and the DC_Offset. However, he said he did not think this would be a realistic equalization model for a Tx. Fangyi said that he expected that Tx equalization should not affect the amplitude or the DC_Offset. Ambrish asked Fangyi if he was suggesting that DC_Offset shouldn't be needed for the Tx. Fangyi agreed. Ambrish noted that he would check with experts in his IP group for their thoughts. He could get info on whether they thought DC_Offset was needed for the Tx, why it was needed, and if it could be affected by Tx equalization. Michael M. noted that he would check with his colleagues as well. Fangyi said this would be good. Fangyi again noted that he didn't think Tx equalization should affect the swing or the DC_Offset, but if it changed one it would change both. Once we get confirmation from others, we might want to add clarification to the BIRD to avoid arbitrary and ambiguous Tx models. Ambrish noted that one reason the Tx might need the DC_Offset was to let it choose the right pre-emphasis option, but it may not need to report the value back. Fangyi noted that the Tx output is limited by Vcc and Vss, regardless of the Tx implementation. Since Vcc and Vss are characterized in the analog channel, the Tx .dll should not change the swing or the IR amplitude. Bob noted two editorial issues with draft3. The first sentence of the Definition section still mentioned InOut. This was an oversight, as all Usages other than In were removed at the last meeting (draft2). Bob also noted that the meaning of "this" in "then this should be the same..." in the final sentence of that paragraph was unclear. Walter and Arpad noted that "this" should be replaced with the parameter name itself "DC_Offset". Michael M. asked if this all still assumed an IR was input to the .dll. Walter confirmed this was true. Michael noted that we wouldn't need DC_Offset if we had a step response or pulse response instead. Walter agreed and noted that there were many ways to solve the problem. We could instead have a BIRD to change the arguments to AMI_Init(), or add a new Reserved parameter to indicate that a step or pulse response were being passed instead, for example. Arpad asked how this would work with BIRD158 style models. Walter noted that BIRD158 models implied a differential Tx and Rx. Arpad said this raised another question, will we have to extend BIRD158 to handle single-ended cases? Walter joked that we might need it for DDR7. Walter noted that DDR5 is only 4 to 5 Gig, and on-die S-parameters as found in BIRD158 are typically used for higher frequency applications. Walter noted that right now DDR5 model makers are using classic IBIS [Model]s and don't need BIRD158. There may be a need to extend BIRD158 in the future, but no IC vendor is asking for it now. Walter noted the comments in today's meeting, but said he would hold off on creating another draft until we got more feedback, including that from Ambrish and Michael after they consult with their co-workers. IBIS-AMI Improvements - Summary of DDR5 issues: Ambrish and Walter said they thought the topic could be removed from the agenda. They noted that the DC_Offset BIRD addressed part of it. The clock-forwarding issue was waiting for feedback from Randy, Michael M., and others. Walter noted that he is working on a paper for the DesignCon IBIS Summit that discusses the rise/fall asymmetry issue and how to address it. Michael M. asked if the asymmetry wouldn't also be addressed if we had the option of a pulse response, or step response, or multiple step responses as opposed to the IR. Walter noted two primary issues: 1. What to do with Init(): We could give Init() two IRs or two step responses (rising/falling), which would require a BIRD, or we could call Init() twice and process the results after the fact, or we could provide a "melded" IR. There are various ways of generating the melded IR. 2. What to do with GetWave(): This is the more critical issue, because it's up to the EDA tool to generate the waveform input to Rx. The method described in IBIS 6.1 is clearly invalid because it only uses one IR and there are really two IRs for the channel (rising/falling). Do we need to change the standard? SiSoft is instead choosing to publish how we do it. Then people can choose to add that approach to the standard or propose a better way instead. No change to the function calls. Even if you changed what you do with Init() to handle two IRs, it's still up the EDA tool to generate the waveform input to the Rx. Fangyi noted that it was important to keep statistical simulation in mind. Walter noted that he inferred from Cadence's DesignCon presentation that they too were using a "melded" IR. They have a PRBS method for generating the melded IR. Walter said SiSoft had several methods of generating the melded IR that do better than using a rising or falling IR. He noted that there are fundamental limitations for statistical simulation with this technique, but it does well if a 10mV error is acceptable. Fangyi asked about an Rx with DFE. If your Rx has DFE then in a statistical flow the Rx will need to add the DFE spikes to the IR. If you only have one IR it's almost impossible to recover the DFE spike information and apply it to other IRs. Ambrish said he thought statistical flow simulation of DFE was already far removed from what's going on in the hardware. Michael M. said that depends. Walter noted that they had done a lot of work with DDR5 DFEs and gotten valid and useful results from statistical simulation. It wasn't as accurate as time domain but was good enough for engineers to make decisions about their channels and margins. Fangyi said some engineers might tolerate a 5 percent difference relative to SPICE, and some might find it a significant error. Arpad returned to the clock-forwarding issue and asked if we needed to do anything in the spec. Walter said what is critical is determining the phase between DQS and DQ. That is determined by the controller as part of a training process. If we add DQS as in input to the Rx model, it has to be trained by the Tx to get the right phase. How would the EDA tool know how to generate the skew? Only the Tx AMI model can do that, presumably using a back-channel type scheme. Fangyi noted that we are talking about the write-cycle in DDR5. Fangyi noted that this issue was related to the fact that at some level we are really trying to model the controller. We generally talk about modeling things at the buffer level, but to address the skew issue we should be talking about the component level. The controller doesn't adjust the individual skew for every I/O. It is actually handled one level above. You might have 64 DQs, but not every one has its own skew. Walter said this was true for DDR3 and DDR4 in particular, but many DDR5 controllers control skew at the individual bit level (not the byte, nibble, lane, etc. like DDR3). Fangyi noted that we also have control and clock and command address lines. We have skew issues for those lines too, and they are not controlled on the individual bit level. Walter agreed that the controller would adjust all those skews to maximize performance. Fangyi noted that they are not adjusted by each command address line model, it's handled "one level above". Walter agreed. Fangyi said it comes back to whether we want to model it at the I/O buffer level or at the component level. Many issues are more naturally modeled at the component level. Walter agreed and said that when we do timing analysis we have to know all the clock to outs, and skews between clocks and data, and they're all part of the timing model. The EDA tool can run the analysis and determine what settings the silicon would come up with if it did train. Fangyi said the EDA tool is acting like the controller, but it's not necessarily doing what the controller would do. Walter said the EDA tool, presumably with an accurate timing model, is figuring out at the component level what all the skews need to be. It may not match exactly what the controller is doing, but presumably you have a timing model that accurately represents what the controller is doing. If we wanted AMI to more strictly emulate the controller's behavior, then you'd need BIRD147 style communication between all the models to try to emulate what the hardware is doing. Fangyi said another alternative was to develop a component level model, which Randy had said would be complicated. Walter agreed. Walter noted that he was involved early on in 802.3. He said that he gave a presentation on IBIS-AMI, and people there rejected anything that involved simulation. Their goal was a standard, you write your Rx according to a certain compliance test, and your channel satisfies it, etc. They don't want their customers to have to simulate anything. They want rules. That's why they came up with things like the Chanel Operating Margin (COM) metric. It's a bit like AMI, and one can create AMI models that satisfy the COM requirements, but simulation is a dirty word to them. Arpad noted the component-level vs buffer-level discussion and asked what we want IBIS to be in the larger context. He noted that we have a few [Component] level things (Pin, Pin_Mapping, etc.). Do we want to refine that component level to do what Fangyi was suggesting? Michael M. noted that even what Arpad had mentioned was at the physical level, and that this was talk of moving up into an architectural level. If we want to move up to architectural level, then we have to be careful to decide what protocol level stuff we need to include as well. We need to be careful or we could end up with mission creep and never get a new version of IBIS done. Walter noted that they had done timing models based on MOTIVE (View Logic) static timing analysis (clock to out, clock skew, set-up and hold times, etc.). The timing model defines what clock to use for setup and hold for these inputs, etc. If IBIS decides we want to develop a standard timing model, he would have no problem putting what they'd done in the public domain, though maybe there would be some issues since it's an enhanced version of a MOTIVE type model. If we decide to do that, then Walter suggested a timing model would be related to a [Component], and it could be included kind of like a [Package Model] is. Arpad asked if we needed to go in that direction, and noted that the clock- forwarding issue touches on the question. Walter noted that we all have timing models. Do EDA companies want a unified way of defining a timing model? Fangyi noted that if we have a component level model, then the timing model and other things can be implemented inside the .dll. - Walter: Motion to adjourn. - Michael M.: Second. - Arpad: Thank you all for joining. AR: Ambrish to check with IP experts on whether DC_Offset is useful for Tx. AR: Michael M. to check with IP experts on whether DC_Offset is useful for Tx. ------------- Next meeting: 27 November 2018 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives